Information drives business. Companies today rely to an unprecedented extent on online, frequently accessed, constantly changing data to run their businesses. Unplanned events that inhibit the availability of this data can seriously damage business operations. Additionally, any permanent data loss, from natural disaster or any other source, will likely have serious negative consequences for the continued viability of a business. Therefore, when disaster strikes, companies must be prepared to eliminate or minimize data loss, and recover quickly with useable data.
Replication technology is primarily used for disaster recovery and data distribution. Periodic replication is one technique utilized to minimize data loss and improve the availability of data in which a point-in-time copy of data is replicated and stored at one or more remote sites or nodes. In the event of a site migration, failure of one or more physical disks storing data, or failure of a node or host data processing system associated with such a disk, the remote replicated data copy may be utilized. In addition to disaster recovery, the replicated data enables a number of other uses, such as, for example, data mining, reporting, testing, and the like. In this manner, the replicated data copy ensures data integrity and availability. Additionally, periodic replication technology is frequently coupled with other high-availability techniques, such as clustering, to provide an extremely robust data storage solution.
Performing a replication operation, backup operation, or the like on a large data set may take a significant amount of time to complete. The sheer size of the data set makes a replication operation take a significant amount of time. During this time, if the data set is maintained live, a problem with intervening accesses to the data set will have to be addressed. For example, on a large enterprise class system, there may be thousands of writes to that data set while it is being backed up or replicated. This factor can create data corruption hazards.
One approach to safely backing up live data is to temporarily disable write access during the backup, for example, by configuring a locking API provided by the file system to enforce exclusive read access. Such an approach might be tolerable for low-availability systems (e.g., desktop computers and small workgroup servers, where regular downtime is acceptable). Enterprise class high-availability 24/7 systems, however, cannot bear service stoppages.
A snapshot, or checkpoint, operation is often used to avoid imposing downtime. To avoid downtime, a high availability system may instead perform the replication or backup on a snapshot, which is essentially a read-only copy of the data set frozen at a point in time, and allow applications to continue writing to their data. Thus the term snapshot is used to refer to the data as they were at a particular point in the past.
Data storage required for applications such as file systems and databases are typically allocated from one or more storage devices that are maintained as a “volume”. The “volume” may serve as a logical interface used by an operating system to access data stored on one or more storage media using a single instance of a file system. Thus, a volume may act as an abstraction that essentially “hides” storage allocation and (optionally) data protection/redundancy from the application. An application can store its data on multiple volumes. The content of a volume is accessed using fixed sized data units called blocks.
Disaster recovery methods typically need to function on frozen time images. Frozen images are required for carrying out any fire drill activities or doing any auxiliary processing on the DR site. In configurations where the LUNs are replicated using HW replication technology the only available solution is using array level snapshots. However this comes at an additional cost of array level snapshot license. Instead if the host based LVM (Logical Volume Manager) could provide the ability to create snapshots on the secondary, then it would be an cost effective solution to the customers.
One method involves using array based snapshots. However, as mentioned in the problem statement this comes at an additional cost. Another method may involve using host based replication. However, this consumes additional resources on the primary server.